I decided to abandon all path based Allow and Deny rules for AppLocker (with one exception on a single PC which I won't describe here). The exceptions under the Windows directory alone were getting numerous and were difficult to find as I described. It simply wasn't a good solution. It is clear that AppLocker is not a security boundary as you describe. The documentation says as much. With that in mind, I have chosen instead to use AppLocker as a reputation boundary. All of my rules are Publisher rules for Microsoft, McAfee, Adobe, etc., and I even included one for our internal CA and started signing my own internal projects. Thus, I can expect some reasonable protection against unsigned .exe's regardless of where they are found within the file system.

The recommended best practice for AppLocker and the (Default Rule) for Program Files is to delete that rule and use the Automatically Generate Rules.. wizard to create Publisher/File Hash rules for just the applications under Program Files that you want to allow users to execute. The (Default Rule) for All files located in the Windows folder seems like a good starting point for allowing full access to the underlying Windows for users. Trying to follow the same best practice approach and add the \Windows directory with the Automatically Generate Rules.. wizard results in many dozens of rules. It's quite unsightly and seems overly complicated. Instead, I'd like to use the (Default Rule) for Windows, but eliminate the security holes as path exceptions. For starters, I mean any subdirectory like C:\Windows\Temp where Users have both read and write access, because such directories would allow users (intentionally or otherwise) to copy executables and subsequently launch them. I can identify such directories pretty quickly with tools like AccessChk from SysInternals, and there are forum posts that itemize them also. What I am having trouble identifying is security points that are equally dangerous but less obvious. For example, a directory where Users have create directory access (perhaps even without read and/or write access at all to that directory), while CREATOR OWNER has full access. That combination allows users to create their own subdirectory with full access. If this occurs under \Windows (as Temp does although previously identified), then that path needs an exception also to AppLocker. This security setup is standard for the root directories of Roaming Profiles and Folder Redirection on file shares (allowing users to create their own full control subfolders without any access to the folders of other users or the root folder itself). Anyone have a good method for finding these?

> The recommended best practice for AppLocker and the (Default Rule) for Program Files is to delete that rule and use the Automatically Generate Rules.. wizard to create Publisher/File Hash rules for just the applications under Program Files that you want to allow users to execute. I'm not sure if this is recommended solution. You need to use path rules for all cases, unless users have write permissions there. > Anyone have a good method for finding these? the best way is to disallow program launching from these folders (system Temp, print spooler and other folders) by using path rules. Note that Applocker is not a security boundary and technically cannot prevent all unwanted applications from launching. Ok, it is possible on a little number of computers, but in large environments this will require too much administrative effort. You need to have a company security policy, that describes user rights and define disciplinary actions for policy violation.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki